One of the most successful business analytical tools is a spreadsheet. In general, a spreadsheet program (also hereafter referred to as a “spreadsheet”) allows a person to specify business data and to formulate operations on the data, to construct simultaneous equations with recursive models, and to perform abstract computations on the data using a macro language. In addition, many spreadsheet programs come with a user interface for managing formulas and presenting results in graphical, tabular along with a variety of other types of formats.
For example, a typical spreadsheet program configures the memory of a computer to resemble the column/row or grid format of an accountant's columnar pad, thus providing a visible calculator for a user. To access information in a spreadsheet, specific locations within the spreadsheet must be communicated to the computer in a format which it can understand. A common scheme for accomplishing this is to assign a number to each row in a spreadsheet, and a letter to each column. To reference a location at column A and row 1 (i.e., the upper-left-hand corner), for example, the user types in “A1”. In this manner, the spreadsheet defines an addressable storage location or “cell” at each intersection of a row with a column.
Unfortunately, the analytical usefulness of database query languages, such as the Structure Query Language (SQL), has not yet measured up to that of spreadsheets. For example, it is generally very cumbersome and in most cases very inefficient to perform inter-row calculations in SQL. In general, this limitation stems from a fundamental problem that results from the lack of a cell concept and cell addressing within SQL and more specifically from the lack of a formula for manipulating data within a cell. Thus, in a typical scenario, data is first extracted from a Relational Database Management System (RDBMS) into a tool like a spreadsheet (or a specialized multi-dimensional analysis tool). Thereafter, the extracted data may be manipulated by executing a set of spreadsheet operations on the data within the spreadsheet.
However, the manipulation of data using these spreadsheet operations can itself introduce certain problems. For example, a typical set of spreadsheet operations provides for two dimensional “row-column” cell addressing, which makes symbolic structured model building difficult. For example, change management is made difficult since adding a computation parameter requires manual spreadsheet changes. In addition, a significant scalability problem exists when the number of formulas becomes large (greater than a few thousand), as spreadsheets do not provide parallel execution. Still further, in a collaborative enterprise setting that contains numerous spreadsheets, consolidation can be extremely difficult. However, if the information on the spreadsheets is not consolidated, it may be nearly impossible to get a picture of a business by querying multiple spreadsheets.
Based on the foregoing, there is a clear need for a mechanism that addresses the problems that are generally associated with the manipulation of data in spreadsheet programs and the issues that typically arise from attempting to perform spreadsheet-like operations on data contained within a RDBMS.